1. Field of the Disclosure
The present disclosure relates to electronic transaction processing. More specifically, the present disclosure is directed to method and system for providing instantaneous merchant information retrieval concerning a merchant involved in a cashless transaction near-instantaneously to permit its use during transaction authorization and/or clearing.
2. Brief Discussion of Related Art
The use of payment devices for a broad spectrum of cashless transactions has become ubiquitous in the current economy, accounting for hundreds of billions of dollars in transactions during 2011 alone. The process and parties involved can be visualized for example as presented in FIG. 1, and can be thought of as a cycle, as indicated by arrow 10. A device holder 12 may present a payment device 14 to a merchant 16 as payment for goods and/or services. For simplicity the payment device 14 is depicted as a credit card, although those skilled in the art will appreciate the present disclosure is equally applicable to any cashless payment device, for example and without limitation contactless RFID-enabled devices including smart cards, NFC-enabled smartphones, electronic mobile wallets or the like. The payment device 14 here is emblematic of any transaction device, real or virtual, by which the device holder 12 as payor and/or the source of funds for the payment may be identified.
In cases where the merchant 16 has an established merchant account with an acquiring bank (also called the acquirer) 20, the merchant communicates with the acquirer to secure payment on the transaction. An acquirer 20 is a party or entity, typically a bank, which is authorized by the network operator 22 to acquire network transactions on behalf of customers of the acquirer 20 (e.g., merchant 16). Occasionally, the merchant 16 does not have an established merchant account with an acquirer 20, but may secure payment on a transaction through a third-party payment provider 18. The third party payment provider 18 does have a merchant account with an acquirer 20, and is further authorized by the acquirer 20 and the network operator 22 to acquire payments on network transactions on behalf of sub-merchants. In this way, the merchant 16 can be authorized and able to accept the payment device 14 from a device holder 12, despite not having a merchant account with an acquirer 20.
The acquirer 20 routes the transaction request to the network operator 22. The data included in the transaction request will identify the source of funds for the transaction. With this information, the network operator routes the transaction to the issuer 24. An issuer 24 is a party or entity, typically a bank, which is authorized by the network operator 22 to issue payment cards 14 on behalf of its customers (e.g., device holder 12) for use in transactions to be completed on the network. The issuer 24 also provides the funding of the transaction to the network provider 22 for transactions that it approves in the process described. The issuer 24 may approve or authorize the transaction request based on criteria such as a device holder's credit limit, account balance, or in certain instances more detailed and particularized criteria including transaction amount, merchant classification, etc., which may optionally be determined in advance in consultation with the device holder and/or a party having financial ownership or responsibility for the account(s) funding the payment device 14, if not solely the device holder 12.
The issuer 24 decision to authorize or decline the transaction is routed through the network operator 22 and acquirer 20, ultimately to the merchant 16 at the point of sale. This entire process is typically carried out by electronic communication, and under routine circumstances (i.e., valid device, adequate funds, etc.) can be completed in a matter of seconds. It permits the merchant 16 to engage in transactions with a device holder 12, and the device holder 12 to partake of the benefits of cashless payment, while the merchant 16 can be assured that payment is secured. This is enabled without the need for a preexisting one-to-one relationship between the merchant 16 and every device holder 12 with whom they may engage in a transaction.
The authorization may also be separate in time from the consummation of the transaction. In some cases, an authorization will be taken by a merchant 16, but payment is not made until goods are delivered or the services performed some time later. In any case, on a periodic basis, e.g., daily, the merchant 16 will submit a batch of completed and authorized transactions to the acquirer 20 to receive payment. The acquirer will in turn look to the network operator for payment in a process called “clearing”. The clearing records, or list of cleared transactions including data relevant thereto in form and content specified by the network operator 22, is transmitted to the issuer 24.
The issuer 24 may then look to its customer, e.g., device holder 12 or other party having financial ownership or responsibility for the account(s) funding the payment device 14, for payment on approved transactions, for example through an existing line of credit where the payment device 14 is a credit card, or from funds on deposit where the payment device 14 is a debit card. The issuer 24 will prepare a periodic statement 26 listing transactions on the account of a device holder 12, including merchant data as provided by the network operator 22.
One problem that arises is poor quality of the data received from an acquirer 20, particularly where the merchant 16 is separated from the acquirer 20 by a third party payment provider 18. If the network operator 22 could accurately assign the location of the merchant during the authorization processing, that location ID would be available, for example to improve fraud monitoring, or to provide and instant rewards and/or do instant at-the-point-of-sale rebates. That service could be made available to other MasterCard operational entities, perhaps even external customers.
FIG. 2 illustrates a process 100 for merchant location assignment using a conventional SQL database. Transaction data 102, including merchant key fields 104 and merchant attributes 106 is received from the acquirer 20. In many cases, the merchant key fields 104 and merchant attributes 106 received from the acquirer 20 is ambiguous to identify the merchant, the transaction location (as compared, for example, to a headquarters of the merchant), or whether the merchant is affiliated with a chain, franchise or the like, where it may be advantageous to consider the merchant as part of a larger aggregate for at least some purposes.
The transaction data 102 is subjected to a merchant scrubbing process 108. The merchant scrubbing process 108 includes the application of a set of scrubbing rules and exceptions 110, for example including address data standardization and/or normalization and the like. The merchant scrubbing process 108 produces scrubbed location data 112. Scrubbed location data 112 includes merchant key fields 104 and merchant attributes 106 received from the acquirer 20 with transaction data 102, as well as the scrubbed fields 114 which are the result of the application of the scrubbing rules and exceptions 110.
A location assignment process 116 queries a relational database 118, alternately referred to as a data warehouse, meaning the specific database 118 or part thereof, or to including the operational characteristics of such data storage. The database 118 stores merchant entries which unambiguously identify characteristics of the merchant (location, affiliation, etc.). The query conventionally involves the use of an SQL database interface or management system, one of which is known by its manufacturer, ORACLE, or an equivalent. The location assignment process 116 may include one or more database queries based upon the scrubbed merchant data fields 114.
Where a suitable match is found in the database 118, the result of the location assignment process 116 would include scrubbed merchant data 119, including the components of the scrubbed location data 112, as well as an assigned merchant location ID 120. Additionally and/or optionally, aggregate merchants, e.g., those belonging to a chain or franchise, would be associated with one another and/or their respective groups as part of the location assignment process 116. Where applicable, the scrubbed merchant data 119 includes an aggregate merchant ID 122. Furthermore, the location scrubbing portion of the merchant data scrubbing process 108 would have used the Oracle only to the extent of logging statistics and rule usage.
The process 100 for merchant location assignment of FIG. 2 and as described above is ordinarily conducted periodically in batches, at least in part because as the database management system is not able to accommodate the throughput requirements to reliably provide a result without delaying the authorization process to an unacceptable degree. Required response times are considered to be at most 100 msec, preferably 50 msec and more preferably 0.5 msec.
A solution to this apparent data deficit problem remains wanting.